Permanent gates do count towards billable events. An event is recorded when your application calls the Statsig SDK to check whether a user should be exposed to a feature gate or experiment, and this includes permanent gates. However, if a permanent gate is set to 'Launched' or 'Disabled', it will always return the default value and stop generating billable exposure events.
During the rollout or test period of a permanent gate, exposures will be collected and results will be measured. This is when the gate is billable. Once you Launch or Disable the gate, it is no longer billable. The differentiation with permanent gates is that it tells our system not to nudge you to clean it up, and that it will end up living in your codebase long term. More details can be found in the permanent and stale gates documentation.
If you want to launch a feature flag, but only set a subset group to true, you can achieve this with a Permanent, non-billable gate that targets a specific set of users. You can toggle off “Measure Metric Lifts”, but keep the gate enabled. You don’t need to click “Launch” using that other workflow.
Marking a gate as permanent effectively turns off billable events. This is a useful feature if you want to target a specific set of users without running up billable events.
Please note that we are continuously working on streamlining this process and improving the user experience. Your feedback is always appreciated.
In order to make the review required criteria narrower for different actions and environments, you can follow these steps:
1. Enabling a flag for themselves: This can be done through overrides in the gate. You can uncheck the requirement for review in the role & access control settings.
2. Disabling review requirements for lower environments: You can configure which environments require reviews via your Project Settings. To do this, go to Project Settings --> Keys & Environments --> tap Edit on Environments.
As a Project Admin, you can also allow yourself and other Project Admins to self-approve review requests. To turn on this setting, navigate to the Project Settings page, click on the Edit button next to Config Review Requirements, and click the checkbox to Allow Project Admins to self-approve reviews.
Please note that any changes to these settings will require approval from currently designated reviewers.
Also, it's important to note that the role-based access control setting is only available for customers in our enterprise tier. You can find more information about our pricing and tiers on our pricing page.
In Statsig, you can use Dynamic Configs to send a different set of values (strings, numbers, etc.) to your clients based on specific user attributes. This is similar to Feature Gates, but you get an entire JSON object you can configure on the server and fetch typed parameters from it. Here's an example from the documentation:
var config = Statsig.GetConfig("awesome_product_details");
You can also use Layers/Experiments to run A/B/n experiments. We offer two APIs, but we recommend the use of layers to enable quicker iterations with parameter reuse.
However, if you're looking to dynamically set a series of flags for a user, you might need to replicate your current system using Statsig's rules. You can create rules based on user attributes and set the value of the flags accordingly.
Remember to provide a StatsigUser object whenever possible when initializing the SDK, passing as much information as possible in order to take advantage of advanced gate and config conditions.
If you're running tests in a full-stack environment and using the Ruby SDK on the server, you can override the flag value locally. Here's the relevant documentation: Local Overrides. This allows you to control the flag values based on your setup.
When using the useGate
hook in the React SDK, if the provider does not wait for initialization and useGate
is called before the initialization completes, it will return false on the initial read. However, once the client eventually initializes, it will cause a re-render of the component that is using the useGate
hook.
This re-render is triggered because the useGate
hook updates its state with the actual value of the gate once initialization is complete. It's important to note that this re-render will occur regardless of whether the gate value is true or false. The key point is that the state of the gate has updated, which triggers the re-render.
For handling loading states while the Statsig client initializes, you can use the isLoading
value. Once the Statsig client state changes, your component will be called again and you can handle the true/false gate state as desired. For more details, refer to the Statsig React SDK documentation.
In the event of encountering unexpected diagnostic results when evaluating a gate on React Native, despite the gate being set to 100% pass and Statsig being initialized, there are several potential causes to consider.
The "Uninitialized" status in evaluationDetails.reason
can occur even after calling .initialize()
and awaiting the result. This issue can be due to several reasons:
1. **Ad Blockers**: Ad blockers can interfere with the initialization network request, causing it to fail.
2. **Network Failures**: Any network issues that prevent the initialization network request from completing successfully can result in an "Uninitialized" status.
3. **Timeouts**: The statsig-js SDK applies a default 3-second timeout on the initialize request. This can lead to more frequent initialization timeouts on mobile clients where users may have slower connections.
If you encounter this issue, it's recommended to investigate the potential causes listed above. Check for the presence of ad blockers, network issues, and timeouts. This will help you identify the root cause and implement the appropriate solution.
It's worth noting that the initCalled: true
value doesn't necessarily mean the initialization succeeded. It's important to check for any errors thrown from the initialization method.
If you're still experiencing issues, it might be helpful to use the debugging tools provided by Statsig. These tools can help you understand why a certain user got a certain value. For instance, you can check the diagnostics tab for higher-level pass/fail/bucketing population sizes over time, and for debugging specific checks, the logstream at the bottom is useful and shows both production and non-production exposures in near real-time.
One potential solution to this issue is to use the waitForInitialization
option. When you don’t use this option, any of your components will be called immediately, regardless of if Statsig has initialized. This can result in 'Uninitialized' exposures. By setting waitForInitialization=true
, you can defer the rendering of those components until after statsig has already initialized. This will guarantee the components aren’t called until initialize has completed, and you won’t see any of those ‘Uninitialized’ exposures being logged. You can find more details in the Statsig documentation.
However, if you can't use waitForInitialization
due to it remounting the navigation stack resulting in a changed navigation state, you can check for initialization through initCompletionCallback
.
You can also verify the initialization by checking the value of isLoading
from useGate
and useConfig
and also initialized
and initStarted
from StatsigContext
.If the issue persists, please reach out to the Statsig team for further assistance.
If you're not seeing any exposure/checks data in the Diagnostics/Pulse Results tabs of the feature gate after launching, there are a few things you might want to check:
1. Ensure that your Server Secret Key is correct. You can find this in the Statsig console under Project Settings > API Keys. 2. Make sure that the name of the feature gate in your function matches exactly with the name of the feature gate you've created in the Statsig console. 3. Verify that the user ID is being correctly set and passed to the StatsigUser object. 4. Check if your environment tier matches the one you've set in the Statsig console.If all these are correct and you're still not seeing any data in the Diagnostics/Pulse Results tabs, it might be a technical issue on our end.
The Statsig SDK batches events and flushes them periodically as well as on shutdown
or flush
. If you are using the SDK in your middleware, it's recommended to call flush
to guarantee events are flushed. For more information, refer to the Statsig documentation.
If you're still not seeing any data, it's possible that there's an issue with event compression. In some cases, disabling event compression can resolve the issue. However, this should be done with caution and only as a last resort, as it may impact performance.
If you're using a specific version of the SDK, you might want to consider downgrading to a previous version, such as v5.13.2, which may resolve the issue.
Remember, if you're still experiencing issues, don't hesitate to reach out to the Statsig team for further assistance.